REMARKS 



Applicants have carefully reviewed the Office Action dated April 5, 2007. 
Reconsideration and favorable action is respectfully requested. 

Claims 1-11, 14-17, 19-24 and 27 stand rejected under 35 U.S.C. § 103(a) as being 
unpatentable over Fortenberry (U.S. Patent No. 6,005,939) in view of Hartman (U.S. Patent No. 
5,960,41 1). This rejection is respectfully traversed in view of the currently presented claims. 

In the prior Office Action, Claims 1, 4, 5, 6, 9, 10, 14, 15, 17-19, 22 and 23 had been 
rejected under 35 U.S.C. § 102(a) as being fully anticipated by Hartman. The Fortenberry 
reference had not been previously cited by the Examiner. Thus, the amendments to the claims by 
Applicants have resulted in the Examiner utilizing the Fortenberry reference in combination with 
Hartman to support a rejection of the above noted claims. Thus, discussion of the Fortenberry 
reference is warranted in some detail as to its applicability to the current claims. 

The Fortenberry reference is directed toward the concept of facilitating access to an 
internet website. In the Background of the Invention section, Fortenberry described the 
technique for conducting business over a public computer network. The example that was 
utilized was a user making a purchase or conducting a transaction over the internet which 
required the user to make a purchase/transaction request followed by input of information such 
as user name, address, social security number, credit card number, etc. (Column 1, lines 13-22.) 
One problem that was noted by Fortenberry is with respect to the user having to re-enter the 
same information for multiple requests, as this could possibly lead to mistakes in entering the 
information. Fortenberry described the goal of the patent as follows: 

It would therefore be desirable to provide a technique for allowing 
a user to specify particular information once and have the 
information be used each time the user accesses any site on the 
public network. (Col. 1, lines 44-47) 
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As such, it can be seen that the primary goal of Fortenberry is to facilitate a user to pre- 
store information such as profile information, and have that information available such that each 
time the user accesses a site on the public network, this information can be reused without the 
requirement to re-enter the information during the purchase/transaction. 

The Examiner initially started out on page 3 with a description of how the combination of 
Fortenberry and Hartman teach a method of processing profile information of a user for 
conducting an online transaction between the user and the vendor. The Examiner specifically 
cited column numbers and line numbers, but did not discuss whether these were column numbers 
and line numbers from Fortenberry or Hartman. Applicants believe that these citations are from 
Fortenberry and this response and the arguments herein assume such. 

The Examiner first discussed that the claim language: 

entering profile information of a user into a profile form at 
a user location disposed on a network prior to conduction of an on- 
line transaction between the user and the vendor. . . 

With respect to this portion of the claim language, the Examiner referred to the disclosure of 
Fortenberry (an assumption for the purpose of this response) beginning at column 7, line 39 and 
extending to line 45. This portion of the specification is set forth as follows: 

First, the user sends a request to generate a passport to passport 
agent 216, as illustrated by process step 400. The passport agent 
receives the request, as illustrated by process step 402, and opens a 
secure communication channel between the passport agent and the 
requesting user, as illustrated by process 404. (Col. 7, lines 39-45) 

This portion of the Fortenberry specification is directed toward the user sending a request to a 
central location in order to create what is termed a "passport." The Examiner then addresses the 
next element of the claim, that element being as follows: 
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issuing to the user a unique code representing stored 
profile information of the user in response to the user transmitting 
the profile form from the user location to a second location on the 
network for storage thereat. . . 

The Examiner finds support for this element at column 7, lines 45-65. That portion of the 
specification in Fortenberry is as follows: 



Passport agent 216 then presents to the user a series of queries 
which may be in the form of menus, as illustrated by process block 
406. In response, the user enters the requested information such as 
social security number, drivers license number, etc., and a 
corresponding level of security to protect the information item, as 
illustrated by process blocks 408 and 410. The user specified 
information is referred to herein as user information or 
environmental variables. The security levels assigned to each item 
of user information or environment variables range from highly 
secure to public. For example, particularly sensitive information 
may be designated as highly secured and assigned a high security 
level of 100 on an exemplary scale of 0-100 levels. Less sensitive 
information may be designated as less secured or even public and 
assigned a lower security level approaching or equal to zero. Next, 
passport agent 216 provides a public key to the user to access the 
passport data, as illustrated by process 418. Finally, the user's 
information which collectively comprises the Internet passport is 
stored and maintained in a highly secured server site on the 
Internet which serves as the passport agent and guarantees the 
integrity of the users passport, as illustrated by process block 420. 
(Col. 7, lines 45-65) 



In this portion of the Fortenberry specification, the series of queries that are provided to the user 
allow the user to input the various information. In addition, the specification sets forth that 
"next, passport agent 216 provides a public key to the user to access the passport data. . . " 
(Column 7, lines 60-61.) However, there is nothing in Fortenberry that states that any profile 
form is filled out and transmitted from the user location to a second location on the network. 
The claim clearly states that the unique code is issued to the user and this code "represents" the 
stored profile information of the user and this issuing step is done in response to the user 
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transmitting the profile form from the user location to the second location. All that Fortenberry 
discloses is the generation of a security key in the form of a public key to the user that the user 
may utilize later when allowing a vendor to access profile information. Thus, although the 
public key is unique, the Fortenberry reference certainly does not disclose that a profile form is 
filled out at a user location and then transmitted to a second location. Clearly, there are a 
plurality of queries that are answered such that the form is actually filled out back at a server 
location, that location being the location that generates the public key. 

The next portion of the claim that the Examiner discussed and which is relevant to this 
discussion is as follows: 

after selecting the product, providing to the vendor location 
by the user the unique code for purchase of the product, during the 
on-line transaction. . . 

The Examiner relies upon the portion of Fortenberry set forth at column 8, lines 31-33 which 
states that "next, the user provides a public key to the vendor, as illustrated in process block 504. 
The public key was previously provided to the user by passport agent 216." The Examiner then 
discusses the section of the claim set forth as follows: 

providing the stored profile information from the second 
location to the vendor location in response to the vendor location 
receiving and processing the unique code. . . 

The Examiner merely states that this is all disclosed in column 8. However, the best description 
of the process flow in Fortenberry is that disclosed with respect to Fig. 2b. That portion of the 
specification associated therewith is described beginning at column 6, line 15 and extending to 
line 46. That portion of the specification is set forth as follows: 

Referring now to FIG. 2B, in general overview, the passport 
system operates in the following manner. User 208 who wishes to 
conduct a transaction at web site 210 requests that passport agent 
216 release specific user information to web site 210. The request 
is made as an encrypted message to passport agent 216. Passport 
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agent 216 has previously been provided a key with which to 
decrypt the encrypted message from user 208. Passport agent 216 
decrypts the request from user 208 to determine, inter alia, the 
particular web site to which a passport of the user 208 should be 
sent. 

Passport agent 216 then provides encrypted data to the particular 
web site here denoted as web site 210. User 208 has previously 
provided to web site 210 a public key with which web site 210 can 
decode the encrypted data provided by passport agent 216. 

The web site 210 receives the encrypted user information (i.e. the 
passport) from passport agent 216 and unlocks the message using 
the public key provided by the user 208. If the web site 210 is 
unable to unlock any of the environment variables in the passport, 
the request is ignored, as explained hereinafter. 

It should be noted that user 208 can provide to web site 210 one of 
several public keys which allow web site 210 to unlock data 
having one of several security levels. For example, user 208 may 
have a first key which unlocks confidential user information in the 
user passport, a second key which unlocks secret user information 
in the user passport and a third key which unlocks top secret user 
information in the user passport. Thus, to unlock all the data in the 
passport, user 208 would have to provide to web site 210 all three 
keys. (Col. 6, lines 15-46) 



To review the process of Fortenberry, in this embodiment, when a user desires to conduct 
commerce with a particular website, the website (210), the user sends a request to the passport 
agent (216) to release specific user information thereto. This request is made as an encrypted 
message which requires the public key. The passport agent then provides the encrypted key to 
the designated website (210) and, since the user had previously provided to the website (210) a 
public key, the website (210) can decode the encrypted data provided by passport agent. 
Therefore, the user must do two things; first, the user must send the public key to the designated 
website and then the user must request the passport agent to release the profile information of the 
user to the website. Since the website will then have the public key, it can read the data provided 
thereto by the passport agent. 
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With respect to this particular embodiment, there are some differences between the claim 
language and the operation as disclosed by Fortenberry. First, the profile information is not 
entered into a profile form at a user location disposed on the network and, thereafter, forwarded 
to the second location which, in response thereto, results in the transmission to the user of a 
unique code. The profile information is entered directly into the website of the passport agent 
and, after entry of the information, a unique code in the form of a public key is then forwarded to 
the user. There are no steps specifically set forth in Fortenberry that an on-line transaction is 
initiated by "selecting" a product of a vendor at a user location; rather, what is done is that a user 
requests a transaction with a particular vendor (column 8, lines 29-30), with no disclosure of the 
selection of any product. The description of Fig. 5, beginning at column 8, line 24, discloses 
that, after a transaction is requested, the next step is to provide a public key to the vendor. The 
user then requests the passport agent to send the user's passport to the vendor and there is no step 
of selecting the product. Further, the claim requires that the stored profile information be 
provided from the second location to the vendor location "in response to" the vendor location 
receiving and processing the code. There is no requirement to process the code by the vendor in 
order for the vendor location to receive the stored profile information. Rather, the user must go 
outside and actually take some action to cause the location at which the stored profile 
information is stored to send this information to the vendor. The public key is only utilized to 
read the information once it is received. Therefore, the portion of the claim that states "in 
response to" with respect to the step of providing cannot be met by Fortenberry. In fact, 
Fortenberry takes a completely different approach in that they specifically require the user to go 
out and make a specific request to the passport agent to send the information to the particular 
website of the vendor. 

The Examiner indicated that Fortenberry taught the operation of passing information 
from a third party to a vendor to process a transaction after receiving a unique identifier 
authorizing the release of sensitive information to the vendor. However, the claim requires 
more. The claim requires that the profile information be entered into a form at the user location 
and then, in response to transmitting the form to the second location, issuing to the user a unique 
code and this unique code represents the stored profile information of the user. Fortenberry does 
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not disclose issuing this code after transmitting the form from the user location to the second 
location. There is no step of initiating an online transaction by selecting a product of the vendor 
at the user location; rather, all that is disclosed is to initiate a request for a transaction. There is 
no discussion as to how the transaction occurs after this. Clearly, there is no step of "after 
selecting the product, providing to the vendor location by the user the unique code for purchase 
of the product" as set forth in the claim that occurs during the on-line transaction. Further, this 
on-line transaction does not require the user to view a vendor payment form as set forth in the 
claim. Since Fortenberry clearly requires that the public key is provided to the vendor after a 
request for transaction and not after selecting the product to be purchased. Fortenberry is 
concerned with identifying the user prior to going forward with the transaction as compared to 
Applicants claim which utilizes the information, i.e., the stored profile information, for 
completing the transaction. Further, the claim requires that the stored profile information be 
provided to the vendor "in response to the vendor location receiving and processing the unique 
code." There is no suggestion or teaching in Fortenberry that would lead one skilled in the art to 
change the operation wherein the user in Fortenberry sends a public key to the vendor and then 
sends a request to the passport agent to send the passport to the vendor to allow a previously 
requested transaction to go forward. The claim clearly requires that the stored profile 
information is a function of the vendor location receiving and processing the unique code. The 
vendor location will not even utilize the unique code until it receives the profile information. 
Therefore, the profile information has to be received before the unique code is even used. This 
portion of the claim is clearly not met by Fortenberry. 

The Examiner has stated that the deficiency in Fortenberry was that it did not specifically 
mention inserting released information into a form automatically before submittal to a user. The 
Examiner relies upon the Hartman reference to support this portion of the rejection. This portion 
was described in the previous response beginning at the bottom of page 14 and extending to the 
top of page 15. This portion is set forth as follows: 

In the last step, at least a portion of the stored profile information is 
inserted into the vendor payment form in respective fields. The 
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only place that there is any remote suggestion of such an action is 
with respect to the original form that was sent to the user, as set 
forth in Figure 1A. In this section, section (103), there is provided 
a button for the transaction and, in addition thereto, other 
information such as address information, links to express ordering, 
etc. Of the information, the only information that is noted is the 
name of the user in position (103b). However, the requirement of 
this step is that, when the user receives the form (noting that this is 
not a payment form but, rather, an information page) for viewing 
after insertion, there is a requirement that this insertion follow the 
steps of selecting a product and then forwarding a unique code to 
the server for the purpose of initiating the on-line transaction, i.e., 
purchasing the product, and then a form sent back to the user 
already filled in. The information is inserted into the web page 
with the description of the product in Hartman prior to the user 
deciding to select that particular product. In Applicant's present 
method, the present inventive concept, as defined by the amended 
claims, requires the selection to have already been made, and the 
providing of the unique code is performed during the on-line 
transaction. 



In view of the above arguments, Applicants believe that the Examiner's rejection of 
Claims 1-11, 14-17, 19-24 and 27 in view of the combination of Fortenberry and Hartman does 
not disclose, nor suggest all of the elements of the claims and the steps therein. As such, 
Applicants respectfully request withdrawal of the 35 U.S.C. § 103(a) with respect to Claims 1- 
11, 14-17, 19-24 and 27 in view of these two references. 

Claims 12 and 25 stand rejected under 35 U.S.C. § 103(a) as being unpatentable over 
Fortenberry in view of Hartman and further in view of Rhoads. This rejection is respectfully 
traversed. 



Claims 12 and 25 depend from claims 1 and 14, as described herein above. The addition 
of Rhoads does not cure the deficiencies noted herein above with respect to the combination of 
Fortenberry and Hartman. Therefore, Applicants respectfully request withdrawal of the 35 
U.S.C. § 103(a) rejection of Claims 12 and 25. 
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Claims 13, 18, 26, 28 and 29 stand rejected under 35 U.S.C. § 103(a) as being 
unpatentable over Fortenberry in view of Hartman and further in view of Rhoads. This rejection 
is respectfully traversed. 

Claims 13, 18, 26, 28 and 29 depend from Claims 1 or 14 and the addition of Rhoads 
does not cure the deficiencies noted herein above with respect to the rejection thereof. 
Therefore, Applicants respectfully request withdrawal of the 35 U.S.C. § 103(a) rejection of 
Claims 13, 18,26, 28 and 29. 

The Examiner has indicated that the arguments over Hartman were moot in view of the 
new grounds of rejection. However, Applicant notes that the Examiner has not commented on 
the detailed analysis of Hartman in Applicants' previous Response with respect to the various 
elements of the claims. The Examiner's statement that "it would have been obvious to a person 
having ordinary skill in the art at the time of the invention to include in Fortenberry the 
confirmation page of Hartman, because this was a notoriously well known means for presenting 
a final order summary that assures the user that the vendor has the order correct" ignores all of 
the limitations and the order of steps which were set forth in the prior Response filed by 
Applicants. Clearly, the discussion of Hartman set forth that one of the deficiencies therein was 
the fact that the webpage presented to the user was presented upon the user's physical device 
accessing the vendor's location such that a "cookie" could be interfaced with. This identifies the 
user to the vendor site and information at that vendor's site is then utilized to provide a web page 
back to a user. However, this information is set at the time of access and not after ordering a 
product or after sending the unique code thereto. Thus, the steps require that, before the filled in 
form is sent to the user, that there be a product selected, a unique code sent thereafter and this 
unique code utilized to complete the transaction. In the Hartman reference, certain identifying 
information is placed into the form and then the user populates the form by selecting items after 
presentation of the form. In Hartman, the user need not see all of the information in the form in 
order to complete the order. For example, the order form in Fig. lc provides information as to 
what has already been ordered, i.e., after the completion of the transaction. Therefore, the web 
page provided to the user is that associated with an order already placed and the purchase 
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completed. The only information provided to the user before the single-action operation is that 
associated with the purchaser such that the purchaser can verify that the service system correctly 
recognizes the purchaser. (Hartman, column 4, lines 37-40.) However, this information is not 
utilized for the purpose of providing to the user a filled in form. In fact, the Hartman reference 
teaches away from providing the user a filled in form; rather, Hartman teaches the use of a 
single-action operation wherein the complete transaction is made without providing to the user a 
form. The only form is that in Fig. lc which is provided to the user "after" the transaction has 
been completed. This is contrary to the purpose of Applicants present inventive concept, which 
is to provide to the user a filled in form that the user can view "prior to completion of the on-line 
transaction." 

Applicants have now made an earnest attempt in order to place this case in condition for 
allowance. For the reasons stated above, Applicants respectfully request full allowance of the 
claims as amended. Please charge any additional fees or deficiencies in fees or credit any 
overpayment to Deposit Account No. 20-0780/PHLY-24,732 of HOWISON & ARNOTT, L.L.P. 

Respectfully submitted, 
HOWISON & ARNOTT, L.L.P. 
Attorneys for Applicant(s) 



/Gregory M. Howison, Reg. #30,646/ 
Gregory M. Howison 
Registration No. 30,646 
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P.O.Box 741715 
Dallas, Texas 75374-1715 
Tel: 972-479-0462 
Fax: 972-479-0464 
May 21, 2007 
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